home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001350_daemon _Fri Jun 18 13:45:52 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  2KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA27127; Fri, 18 Jun 93 13:45:54 MET DST
  3. Return-Path: <nikos@cbl.leeds.ac.uk>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA27123; Fri, 18 Jun 93 13:45:52 MET DST
  6. Received: from chx400.switch.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA27235; Fri, 18 Jun 1993 14:08:07 +0200
  8. X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/;
  9.                Relayed; Fri, 18 Jun 1993 14:07:49 +0200
  10. X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed;
  11.                Fri, 18 Jun 1993 14:06:30 +0200
  12. X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
  13.                Fri, 18 Jun 1993 14:06:04 +0200
  14. X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
  15.                Fri, 18 Jun 1993 14:06:04 +0200
  16. Date: Fri, 18 Jun 1993 14:06:04 +0200
  17. X400-Originator: nikos@cbl.leeds.ac.uk
  18. X400-Recipients: www-talk@NXOC01.cern.ch
  19. X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<26583.9306181206@cbl.leeds.ac.u]
  20. X400-Content-Type: P2-1984 (2)
  21. Content-Identifier: Re: HTML+ sup...
  22. From: N F Drakos <nikos@cbl.leeds.ac.uk>
  23. Message-Id: <26583.9306181206@cbl.leeds.ac.uk>
  24. To: www-talk <www-talk@nxoc01.cern.ch>
  25. Subject: Re: HTML+ support for eqn & Postscript
  26.  
  27. >We use (amongst other things) DECWrite, which deals with equations by
  28. >embedding limited, math only, TeX code (actually stored in a separate
  29. >file), and translating it to DECwrite's internal format for final
  30. >display. It works well. DEC saw no reason to invent a new format, and
  31. >given that TeX already exists, I  see no point in reinventing it,
  32. >either. Face it, the hard bit has been done - the browser author
  33. >doesn't have to know what the Tex code *does*, simply hand the input to
  34. >it and render the output. Yes, I know it's not trivial for browser
  35. >authors, but my guess is that reinventing maths symbol processing for
  36. >HTML would be worse. Do the TeX stuff in a separate process, if you
  37. >like. Ghostscript takes this approach of separating viewer and processor, I
  38. > believe.
  39. > 
  40.  
  41. I agree. We are taking this approach in a tex2html translator we are
  42. currently building.
  43. The idea is to translate into HTML as much as possible and include
  44. the rest (pictures, equations, tables, etc.) as inlined images.
  45. Then, an HTML viewer need only handle inlined images and allow text to
  46. flow around them. 
  47.  
  48. Nikos Drakos,
  49. Computer Based Learning Unit, University of Leeds.
  50.  
  51.